`beforeDevCommand` runs with `"wait": false`, so Tauri spawns
`bun run dev` without reaping it, and `bun` spawns `vite` as a
grandchild. When Tauri exits, that grandchild survives holding port
5173. Because `devUrl` pins that exact port, the next `just dev` fails
outright rather than reusing or relocating:

    error when starting dev server:
    Error: Port 5173 is already in use
    Error The "beforeDevCommand" terminated with a non-zero status code.

Every second launch failed until the stray process was killed by hand.

The pattern is the repo-local vite binary path, so it cannot match a dev
server belonging to another project on the same machine.

WHY `[v]ite` rather than `vite`: `pkill -f` matches the full command line
of every process, including the shell running the recipe — whose argv
contains the pattern verbatim. Spelled plainly, pkill kills its own shell
and the recipe dies with exit 144 before reaching the `tauri dev` line.
Verified both ways against a scratch justfile: `vite` reproduces the
self-kill, `[v]ite` prints the following line and exits 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Scanning records where files were; nothing afterwards noticed when one
went away. The filesystem watcher only sees deletions that happen while
it is running, so a file removed with the app closed stayed `Active` in
the catalogue forever. `perima verify` walks every location on a mounted
volume, stats it, and writes back the statuses that changed — both
directions, so a file that comes back returns to `Active` rather than
being stuck `Missing`.

This has to exist before any prune: deleting rows marked `Missing` is
only as trustworthy as whatever marked them.

## The unmounted-volume rule is structural, not documented

`list_locations_for_verify` INNER JOINs `volume_mounts`, so a location
whose volume is not mounted does not appear in the result set at all —
it is not returned with a NULL path for the caller to remember to
filter. The sweep marks everything it receives and cannot stat as
`Missing`, so one leaked row for an unplugged external drive becomes a
false `Missing`, and a prune then deletes a catalogue whose files are
intact in a drawer. Making absence structural means no caller can get
this wrong.

The count of excluded rows travels back with the rows themselves
(`VerifyCandidates`) rather than being an optional second query. A sweep
that silently omits an unmounted drive reports "checked 78, no changes"
over a 500-file library and reads as a clean bill of health; carrying
the number the caller may NOT conclude anything about makes an honest
report the path of least resistance. `VerifyReport::is_complete()` is
the single predicate a destructive caller should gate on.

## machine_id

The mount join is scoped to the calling device. `volume_mounts` is keyed
on `(volume_id, machine_id)`, and joining without that predicate pairs a
local row with another computer's mount path — the sweep would then stat
paths that mean nothing here and mark the whole local catalogue
`Missing`. Three older queries in `file_repo.rs` omit the predicate;
that is #195, left alone here so the trait-signature change lands as its
own reviewable commit.

## Other decisions

- `symlink_metadata`, not `metadata`: a symlink whose target is gone
  still has an entry at the catalogued path. Whether the target is
  healthy is the hashing path's question.
- `Moved` and `Stale` are left untouched when the file is present. This
  sweep only looked at existence, so it only writes the present/absent
  axis; downgrading either to `Active` would discard information it did
  not earn.
- Status writes go through one batched transaction. Per-row writes would
  open one `BEGIN IMMEDIATE` per changed file — the write-amplification
  shape that provoked the SQLite lock-order inversion in #131. One `hlc`
  covers the batch: a sweep is one logical event, and every row it
  touched observed the same filesystem state.
- A cancelled sweep writes nothing and reports `completed: false`.

Verified end-to-end against a real 78-file library: a clean sweep reports
no changes; hiding a file makes the next sweep mark exactly that row
`missing`; restoring it makes the following sweep report it recovered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds `perima prune` plus the `verify_locations`, `count_missing_locations`
and `prune_missing_locations` Tauri commands, so both shells can act on
what a verify sweep found.

Prune soft-deletes `file_locations` rows whose status is `missing`. It
performs no filesystem check of its own — deciding what is missing needs
a `stat()` per file, which must not happen inside a write transaction
holding the write lock. That split means a prune is exactly as
trustworthy as the sweep before it, which is why both surfaces push the
user toward running `verify` first.

Soft-delete rather than `DELETE FROM`: `file_locations` is CRDT-
replicated, a hard delete has no merge representation, and the row would
resurrect on the next sync from any peer that still holds it. Same
convention as the `update_location_path` collision branch.

## Confirmation

The CLI requires an explicit `--yes` for a live run and otherwise prints
the count with a pointer to `--dry-run`. The desktop hides the prune
control entirely when nothing is missing rather than showing it disabled
— a greyed "Remove 0 missing" invites a click to find out what it does —
and requires a second click that restates the number.

Prune is also a no-op when the count is zero: an empty destructive write
still takes the write lock and still emits an invalidation the frontend
would act on.

`verify_locations` runs on `spawn_blocking`. The sweep issues one
`symlink_metadata` per catalogued file, and a large library would
otherwise stall the async runtime thread the Tauri command is polled on.

## IPC arg names

All three commands take their arguments under the camelCase keys Tauri
converts to, and the `ipc-contract` test covers them. Confirmed the test
actually discriminates by flipping `dryRun` to `dry_run` and watching it
fail with the exact diagnostic, rather than trusting a green run:

    verify_locations: expected key "dryRun" (Rust param `dry_run`),
    api.ts sends [dry_run]

That is the #180 bug class, which shipped broken precisely because it
was assumed both spellings worked.

Verified end-to-end on a real library: verify marks one hidden file
missing, prune without `--yes` refuses, `--dry-run` reports 1, `--yes`
retires the row (78 active -> 77 active + 1 soft-deleted).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The catalogue has tracked whether a file is still on disk since v1, and
`payloads.rs` has been shipping that status to the frontend the whole
time — where `FileTable` rendered it as bare lowercase text in the fifth
of six columns, visually identical to every other cell. The information
was present and invisible.

`LocationStatusBadge` gives the abnormal states a treatment and leaves
`active` muted. Colouring the normal case too would drown the one row
that matters, since almost every row is active. Missing rows also drop
to 50% opacity across the whole row: the status column is easy to miss
when scanning by filename, and desaturating the row makes "not on disk"
legible peripherally while the badge carries the precise verdict.
Opacity only — the row stays selectable so it can be inspected.

Meaning is carried in text as well as colour (`sr-only` description per
state), so the signal survives assistive tech and colour blindness. An
unrecognised status renders neutrally rather than blanking the cell —
`status` is a plain text column in SQLite and a future backend variant
must not break the table.

`LibraryHealthPill` in the status bar exposes the two actions. They stay
separate buttons rather than one "clean up": verify is safe and
repeatable, prune deletes rows, and fusing them would mean a single
click both decides what is missing and acts on it with no moment to look
at the number. The prune control is absent, not disabled, when nothing
is missing.

The verify notification always states `skipped_unmounted` when non-zero.
A sweep that could not see an unmounted drive would otherwise report
"checked 0 · no changes" and read as a healthy library — which is
exactly what happened on the first live run here, where CLI and desktop
turned out to hold different device ids (#192) and every location was
skipped. That surfaced only because the count is mandatory.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>